home *** CD-ROM | disk | FTP | other *** search
/ SGI Developer Toolbox 6.1 / SGI Developer Toolbox 6.1 - Disc 4.iso / documents / RFC / rfc1063.txt < prev    next >
Text File  |  1994-08-01  |  27KB  |  619 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                      J.  Mogul
  8. Request For Comments: 1063                                   C. Kent
  9.                                                                  DEC
  10.                                                         C. Partridge
  11.                                                                  BBN
  12.                                                        K. McCloghrie
  13.                                                                  TWG
  14.                                                            July 1988
  15.  
  16.  
  17.                         IP MTU Discovery Options
  18.  
  19. STATUS OF THIS MEMO
  20.  
  21.    A pair of IP options that can be used to learn the minimum MTU of a
  22.    path through an internet is described, along with its possible uses.
  23.    This is a proposal for an Experimental protocol.  Distribution of
  24.    this memo is unlimited.
  25.  
  26. INTRODUCTION
  27.  
  28.    Although the Internet Protocol allows gateways to fragment packets
  29.    that are too large to forward, fragmentation is not always desirable.
  30.    It can lead to poor performance or even total communication failure
  31.    in circumstances that are surprisingly common.  (For a thorough
  32.    discussion of this issue, see [1]).
  33.  
  34.    A datagram will be fragmented if it is larger than the Maximum
  35.    Transmission Unit (MTU) of some network along the path it follows.
  36.    In order to avoid fragmentation, a host sending an IP datagram must
  37.    ensure that the datagram is no larger than the Minimum MTU (MINMTU)
  38.    over the entire path.
  39.  
  40.    It has long been recognized that the methods for discovering the
  41.    MINMTU of an IP internetwork path are inadequate.  The methods
  42.    currently available fall into two categories: (1) choosing small MTUs
  43.    to avoid fragmentation or (2) using additional probe packets to
  44.    discover when fragmentation will occur.  Both methods have problems.
  45.  
  46.    Choosing MTUs requires a balance between network utilization (which
  47.    requires the use of the largest possible datagram) and fragmentation
  48.    avoidance (which in the absence of knowledge about the network path
  49.    encourages the use of small, and thus too many, datagrams).  Any
  50.    choice for the MTU size, without information from the network, is
  51.    likely to either fail to properly utilize the network or fail to
  52.    avoid fragmentation.
  53.  
  54.    Probe packets have the problem of burdening the network with
  55.  
  56.  
  57.  
  58. Mogul, Kent, Partridge, & McCloghrie                            [Page 1]
  59.  
  60. RFC 1063                IP MTU Discovery Options               July 1988
  61.  
  62.  
  63.    unnecessary packets.  And because network paths often change during
  64.    the lifetime of a TCP connection, probe packets will have to be sent
  65.    on a regular basis to detect any changes in the effective MINMTU.
  66.  
  67.    Implementors sometimes mistake the TCP MSS option as a mechanism for
  68.    learning the network MINMTU.  In fact, the MSS option is only a
  69.    mechanism for learning about buffering capabilities at the two TCP
  70.    peers.  Separate provisions must be made to learn the IP MINMTU.
  71.  
  72.    In this memo, we propose two new IP options that, when used in
  73.    conjunction will permit two peers to determine the MINMTU of the
  74.    paths between them.  In this scheme, one option is used to determine
  75.    the lowest MTU in a path; the second option is used to convey this
  76.    MTU back to the sender (possibly in the IP datagram containing the
  77.    transport acknowledgement to the datagram which contained the MTU
  78.    discovery option).
  79.  
  80. OPTION FORMATS
  81.  
  82.    Probe MTU Option (Number 11)
  83.  
  84.       Format
  85.  
  86.               +--------+--------+--------+--------+
  87.               |00001011|00000100|   2 octet value |
  88.               +--------+--------+--------+--------+
  89.  
  90.       Definition
  91.  
  92.       This option always contains the lowest MTU of all the networks
  93.       that have been traversed so far by the datagram.
  94.  
  95.       A host that sends this option must initialize the value field to
  96.       be the MTU of the directly-connected network.  If the host is
  97.       multi-homed, this should be for the first-hop network.
  98.  
  99.       Each gateway that receives a datagram containing this option must
  100.       compare the MTU field with the MTUs of the inbound and outbound
  101.       links for the datagram.  If either MTU is lower than the value in
  102.       the MTU field of the option, the option value should be set to the
  103.       lower MTU.  (Note that gateways conforming to RFC-1009 may not
  104.       know either the inbound interface or the outbound interface at the
  105.       time that IP options are processed.  Accordingly, support for this
  106.       option may require major gateway software changes).
  107.  
  108.       Any host receiving a datagram containing this option should
  109.       confirm that value of the MTU field of the option is less than or
  110.       equal to that of the inbound link, and if necessary, reduce the
  111.  
  112.  
  113.  
  114. Mogul, Kent, Partridge, & McCloghrie                            [Page 2]
  115.  
  116. RFC 1063                IP MTU Discovery Options               July 1988
  117.  
  118.  
  119.       MTU field value, before processing the option.
  120.  
  121.       If the receiving host is not able to accept datagrams as large as
  122.       specified by the value of the MTU field of the option, then it
  123.       should reduce the MTU field to the size of the largest datagram it
  124.       can accept.
  125.  
  126.    Reply MTU Option (Number 12)
  127.  
  128.       Format
  129.  
  130.               +--------+--------+--------+--------+
  131.               |00001100|00000100|   2 octet value |
  132.               +--------+--------+--------+--------+
  133.  
  134.       Definition
  135.  
  136.       This option is used to return the value learned from a Probe MTU
  137.       option to the sender of the Probe MTU option.
  138.  
  139. RELATION TO TCP MSS
  140.  
  141.    Note that there are two superficially similar problems in choosing
  142.    the size of a datagram.  First, there is the restriction [2] that a
  143.    host not send a datagram larger than 576 octets unless it has
  144.    assurance that the destination is prepared to accept a larger
  145.    datagram.  Second, the sending host should not send a datagram larger
  146.    than MINMTU, in order to avoid fragmentation.  The datagram size
  147.    should normally be the minimum of these two lower bounds.
  148.  
  149.    In the past, the TCP MSS option [3] has been used to avoid sending
  150.    packets larger than the destination can accept.  Unfortunately, this
  151.    is not the most general mechanism; it is not available to other
  152.    transport layers, and it cannot determine the MINMTU (because
  153.    gateways do not parse TCP options).
  154.  
  155.    Because the MINMTU returned by a probe cannot be larger than the
  156.    maximum datagram size that the destination can accept, this IP option
  157.    could, in theory, supplant the use of the TCP MSS option, providing
  158.    an economy of mechanism.  (Note however, that some researchers
  159.    believe that the value of the TCP MSS is distinct from the path's
  160.    MINMTU.  The MSS is the upper limit of the data size that the peer
  161.    will accept, while the MINMTU represents a statement about the data
  162.    size supported by the path).
  163.  
  164.    Note that a failure to observe the MINMTU restriction is not normally
  165.    fatal; fragmentation will occur, but this is supposed to work.  A
  166.    failure to observe the TCP MSS option, however, could be fatal
  167.  
  168.  
  169.  
  170. Mogul, Kent, Partridge, & McCloghrie                            [Page 3]
  171.  
  172. RFC 1063                IP MTU Discovery Options               July 1988
  173.  
  174.  
  175.    because it might lead to datagrams that can never be accepted by the
  176.    destination.  Therefore, unless and until the Probe MTU option is
  177.    universally implemented, at least by hosts, the TCP MSS option must
  178.    be used as well.
  179.  
  180. IMPLEMENTATION APPROACHES
  181.  
  182.    Who Sends the Option
  183.  
  184.       There are at least two ways to implement the MTU discovery scheme.
  185.       One method makes the transport layer responsible for MTU
  186.       discovery; the other method makes the IP layer responsible for MTU
  187.       discovery.  A host system should support one of the two schemes.
  188.  
  189.    Transport Discovery
  190.  
  191.       In the transport case, the transport layer can include the Probe
  192.       MTU option in an outbound datagram.  When a datagram containing
  193.       the Probe MTU option is received, the option must be passed up to
  194.       the receiving transport layer, which should then acknowledge the
  195.       Probe with a Reply MTU option in the next return datagram.  Note
  196.       that because the options are placed on unreliable datagrams, the
  197.       original sender will have to resend Probes (possibly once per
  198.       window of data) until it receives a Reply option.  Also note that
  199.       the Reply MTU option may be returned on an IP datagram for a
  200.       different transport protocol from which it was sent (e.g., TCP
  201.       generated the probe but the Reply was received on a UDP datagram).
  202.  
  203.    IP Discovery
  204.  
  205.       A better scheme is to put MTU discovery into the IP layer, using
  206.       control mechanisms in the routing cache.  Whenever an IP datagram
  207.       is sent, the IP layer checks in the routing cache to see if a
  208.       Probe or Reply MTU option needs to be inserted in the datagram.
  209.       Whenever a datagram containing either option is received, the
  210.       information in those options is placed in the routing cache.
  211.  
  212.       The basic working of the protocol is somewhat complex.  We trace
  213.       it here through one round-trip.  Implementors should realize that
  214.       there may be cases where both options are contained in one
  215.       datagram.  For the purposes of this exposition, the sender of the
  216.       probe is called the Probe-Sender and the receiver, Probe-Receiver.
  217.  
  218.       When the IP layer is asked to send a Probe MTU option (see the
  219.       section below on when to probe), it makes some record in the
  220.       routing cache that indicates the next IP datagram to Probe-
  221.       Receiver should contain the Probe MTU option.
  222.  
  223.  
  224.  
  225.  
  226. Mogul, Kent, Partridge, & McCloghrie                            [Page 4]
  227.  
  228. RFC 1063                IP MTU Discovery Options               July 1988
  229.  
  230.  
  231.       When the next IP datagram to Probe-Receiver is sent, the Probe MTU
  232.       option is inserted.  The IP layer in Probe-Sender should continue
  233.       to send an occasional Probe MTU in subsequent datagrams until a
  234.       Reply MTU option is received.  It is strongly recommended that the
  235.       Probe MTU not be sent in all datagrams but only at such a rate
  236.       that, on average, one Probe MTU will be sent per round-trip
  237.       interval.  (Another way of saying this is that we would hope that
  238.       only one datagram in a transport protocol window worth of data has
  239.       the Probe MTU option set).  This mechanism might be implemented by
  240.       sending every Nth packet, or, in those implementations where the
  241.       round-trip time estimate to the destination is cached with the
  242.       route, once every estimated RTT.
  243.  
  244.       When a Probe MTU option is received by Probe-Receiver, the
  245.       receiving IP should place the value of this option in the next
  246.       datagram it sends back to Probe-Sender.  The value is then
  247.       discarded.  In other words, each Probe MTU option causes the Reply
  248.       MTU option to be placed in one return datagram.
  249.  
  250.       When Probe-Sender receives the Reply MTU option, it should check
  251.       the value of the option against the current MINMTU estimate in the
  252.       routing cache.  If the option value is lower, it becomes the new
  253.       MINMTU estimate.  If the option value is higher, Probe-Sender
  254.       should be more conservative about changing the MINMTU estimate.
  255.       If a route is flapping, the MINMTU may change frequently.  In such
  256.       situations, keeping the smallest MINMTU of various routes in use
  257.       is preferred.  As a result, a higher MINMTU estimate should only
  258.       be accepted after a lower estimate has been permitted to "age" a
  259.       bit.  In other words, if the probe value is higher than the
  260.       estimated MINMTU, only update the estimate if the estimate is
  261.       several seconds old or more.  Finally, whenever the Probe-Sender
  262.       receives a Reply MTU option, it should stop retransmitting probes
  263.       to Probe-Receiver.
  264.  
  265.       A few additional issues complicate this discussion.
  266.  
  267.       One problem is setting the default MINMTU when no Reply MTU
  268.       options have been received.  We recommend the use of the minimum
  269.       of the supported IP datagram size (576 octets) and the connected
  270.       network MTU for destinations not on the local connected network,
  271.       and the connected network MTU for hosts on the connected network.
  272.  
  273.       The MINMTU information, while kept by the Internet layer, is in
  274.       fact, only of interest to the transport and higher layers.
  275.       Accordingly, the Internet layer must keep the transport layer
  276.       informed of the current value of the estimated MINMTU.
  277.       Furthermore, minimal transport protocols, such as UDP, must be
  278.       prepared to pass this information up to the transport protocol
  279.  
  280.  
  281.  
  282. Mogul, Kent, Partridge, & McCloghrie                            [Page 5]
  283.  
  284. RFC 1063                IP MTU Discovery Options               July 1988
  285.  
  286.  
  287.       user.
  288.  
  289.       It is expected that there will be a transition period during which
  290.       some hosts support this option and some do not.  As a result,
  291.       hosts should stop sending Probe MTU options and refuse to send any
  292.       further options if it does not receive either a Probe MTU option
  293.       or Reply MTU option from the remote system after a certain number
  294.       of Probe MTU options have been sent.  In short, if Probe-Sender
  295.       has sent several probes but has gotten no indication that Probe-
  296.       Receiver supports MTU probing, then Probe-Sender should assume
  297.       that Probe-Receiver does not support probes.  (Obviously, if
  298.       Probe-Sender later receives a probe option from Probe-Receiver, it
  299.       should revise its opinion.)
  300.  
  301.       Implementations should not assume that routes to the same
  302.       destination that have a different TOS have the same estimated
  303.       MINMTU.  We recommend that the MTU be probed separately for each
  304.       TOS.
  305.  
  306.    Respecting the TCP MSS
  307.  
  308.       One issue concerning TCP MSS is that it is usually negotiated
  309.       assuming an IP header that contains no options.  If the transport
  310.       layer is sending maximum size segments, it may not leave space for
  311.       IP to fit the options into the datagram.  Thus, insertion of the
  312.       Probe MTU or Reply MTU option may violate the MSS restriction.
  313.       Because, unlike other IP options, the MTU options can be inserted
  314.       without the knowledge of the transport layer, the implementor must
  315.       carefully consider the implications of adding options to an IP
  316.       datagram.
  317.  
  318.       One approach is to reserve 4 bytes from the MINMTU reported to the
  319.       transport layer; this will allow the IP layer to insert at least
  320.       one MTU option in every datagram (it can compare the size of the
  321.       outgoing datagram with the MINMTU stored in the route cache to see
  322.       how much room there actually is).  This is simple to implement,
  323.       but does waste a little bandwidth in the normal case.
  324.  
  325.       Another approach is to provide a means for the IP layer to notify
  326.       the transport layer that space must be reserved for sending an
  327.       option; the transport layer would then make a forthcoming segment
  328.       somewhat smaller than usual.
  329.  
  330.    When a Probe Can Be Sent
  331.  
  332.       A system that receives a Probe MTU option should always respond
  333.       with a Reply MTU option, unless the probe was sent to an IP or LAN
  334.       broadcast address.
  335.  
  336.  
  337.  
  338. Mogul, Kent, Partridge, & McCloghrie                            [Page 6]
  339.  
  340. RFC 1063                IP MTU Discovery Options               July 1988
  341.  
  342.  
  343.       A Probe MTU option should be sent in any of the following
  344.       situations:
  345.  
  346.          (1) The MINMTU for the path is not yet known;
  347.  
  348.          (2) A received datagram suffers a fragmentation re-assembly
  349.              timeout. (This is a strong hint the path has changed;
  350.              send a probe to the datagram's source);
  351.  
  352.          (3) An ICMP Time Exceeded/Fragmentation Reassembly Timeout is
  353.              received (this is the only message we will get that
  354.              indicates fragmentation occurred along the network path);
  355.  
  356.          (4) The transport layer requests it.
  357.  
  358.       Implementations may also wish to periodically probe a path, even
  359.       if there is no indication that fragmentation is occurring.  This
  360.       practice is perfectly reasonable; if fragmentation and reassembly
  361.       is working perfectly, the sender may never get any indication that
  362.       the path MINMTU has changed unless a probe is sent.  We recommend,
  363.       however, that implementations send such periodic probes sparingly.
  364.       Once every few minutes, or once every few hundred datagrams is
  365.       probably sufficient.
  366.  
  367.       There are also some scenarios in which the Probe MTU should not be
  368.       sent, even though there may be some indication of an MINMTU
  369.       change:
  370.  
  371.          (1) Probes should not be sent in response to the receipt of
  372.              a probe option.  Although the fact that the remote peer
  373.              is probing indicates that the MINMTU may have changed,
  374.              sending a probe in response to a probe causes a continuous
  375.              exchange of probe options.
  376.  
  377.          (2) Probes must not be sent in response to fragmented
  378.              datagrams except when the fragmentation reassembly
  379.              of the datagram fails.  The problem in this case is
  380.              that the receiver has no mechanism for informing the remote
  381.              peer that fragmentation has occurred, unless fragmentation
  382.              reassembly fails (in which case an ICMP message is sent).
  383.              Thus, a peer may use the wrong MTU for some time before
  384.              discovering a problem.  If we probe on fragmented
  385.              datagrams, we may probe, unnecessarily, for some time
  386.              until the remote peer corrects its MTU.
  387.  
  388.          (3) For compatibility with hosts that do not implement the
  389.              option, no Probe MTU Option should be sent more than
  390.              ten times without receiving a Reply MTU Option or a
  391.  
  392.  
  393.  
  394. Mogul, Kent, Partridge, & McCloghrie                            [Page 7]
  395.  
  396. RFC 1063                IP MTU Discovery Options               July 1988
  397.  
  398.  
  399.              Probe MTU Option from the remote peer.  Peers which
  400.              ignore probes and do not send probes must be treated
  401.              as not supporting probes.
  402.  
  403.          (4) Probes should not be sent to an IP or LAN broadcast
  404.              address.
  405.  
  406.          (5) We recommend that Probe MTUs not be sent to other hosts
  407.              on the directly-connected network, but that this feature
  408.              be configurable.  There are situations (for example, when
  409.              Proxy ARP is in use) where it may be difficult to determine
  410.              which systems are on the directly-connected network.  In
  411.              this case, probing may make sense.
  412.  
  413. SAMPLE IMPLEMENTATION SKETCH
  414.  
  415.    We present here a somewhat more concrete description of how an IP-
  416.    layer implementation of MTU probing might be designed.
  417.  
  418.    First, the routing cache entries are enhanced to store seven
  419.    additional values:
  420.  
  421.       MINMTU: The current MINMTU of the path.
  422.  
  423.       ProbeRetry: A timestamp indicating when the next probe
  424.                   should be sent.
  425.  
  426.       LastDecreased: A timestamp showing when the MTU was
  427.                      last decreased.
  428.  
  429.       ProbeReply: A bit indicating a Reply MTU option should be
  430.                   sent.
  431.  
  432.       ReplyMTU: The value to go in the Reply MTU option.
  433.  
  434.       SupportsProbes: A bit indicating that the remote peer
  435.                       can deal with probes (always defaults to
  436.                       1=true).
  437.  
  438.       ConsecutiveProbes: The number of probes sent without
  439.                          the receipt of a Probe MTU or Reply
  440.                          MTU option.
  441.  
  442.    There are also several configuration parameters; these should be
  443.    configurable by appropriate network management software; the values
  444.    we suggest are "reasonable":
  445.  
  446.       Default_MINMTU: The default value for the MINMTU field of the
  447.  
  448.  
  449.  
  450. Mogul, Kent, Partridge, & McCloghrie                            [Page 8]
  451.  
  452. RFC 1063                IP MTU Discovery Options               July 1988
  453.  
  454.  
  455.                       routing cache entry, to be used when the real
  456.                       MINMTU is unknown.  Recommended value: 576.
  457.  
  458.       Max_ConsecutiveProbs: The maximum number of probes to send
  459.                             before assuming that the destination does
  460.                             not support the probe option.
  461.                             Recommended value: 10.
  462.  
  463.       ProbeRetryTime: The time (in seconds) to wait before retrying
  464.                       an unanswered probe.  Recommended value:
  465.                       60 seconds, or 2*RTT if the the RTT is available
  466.                       to the IP layer.
  467.  
  468.       ReprobeInterval: The time to wait before sending a probe after
  469.                        receiving a successful Reply MTU, in order to
  470.                        detect increases in the route's MINMTU.
  471.                        Recommended value: 5 times the ProbeRetryTime.
  472.  
  473.       IncreaseInterval: The time to wait before increasing the MINMTU
  474.                         after the value has been decreased, to prevent
  475.                         flapping.  Recommended value: same as
  476.                         ProbeRetryTime.
  477.  
  478.    When a new route is entered into the routing cache, the initial
  479.    values should be set as follows:
  480.  
  481.       MINMTU = Default_MINMTU
  482.  
  483.       ProbeRetry = Current Time
  484.  
  485.       LastDecreased = Current Time - IncreaseInterval
  486.  
  487.       ProbeReply = false
  488.  
  489.       SupportsProbes = true
  490.  
  491.       ConsecutiveProbes = 0
  492.  
  493.    This initialization is done before attempting to send the first
  494.    packet along this route, so that the first packet will contain a
  495.    Probe MTU option.
  496.  
  497.    Whenever the IP layer sends a datagram on this route it checks the
  498.    SupportsProbes bit to see if the remote system supports probing.  If
  499.    the SupportsProbes bit is set, and the timestamp in ProbeRetry is
  500.    less than or equal to the current time, a Probe option should be sent
  501.    in the datagram, and the ProbeRetry field incremented by
  502.    ProbeRetryTime.
  503.  
  504.  
  505.  
  506. Mogul, Kent, Partridge, & McCloghrie                            [Page 9]
  507.  
  508. RFC 1063                IP MTU Discovery Options               July 1988
  509.  
  510.  
  511.    Whether or not the Probe MTU option is sent in a datagram, if the
  512.    ProbeReply bit is set, then a Reply MTU option with the value of the
  513.    ReplyMTU field is placed in the outbound datagram.  The ProbeReply
  514.    bit is then cleared.
  515.  
  516.    Every time a Probe option is sent, the ConsecutiveProbes value should
  517.    be incremented.  If this value reaches Max_ConsecutiveProbes, the
  518.    SupportsProbe bit should be cleared.
  519.  
  520.    When an IP datagram containing the Probe MTU option is received, the
  521.    receiving IP sets the ReplyMTU to the Probe MTU option value and sets
  522.    the ProbeReply bit in its outbound route to the source of the
  523.    datagram.  The SupportsProbe bit is set, and the ConsecutiveProbes
  524.    value is reset to 0.
  525.  
  526.    If an IP datagram containing the Reply MTU option is received, the IP
  527.    layer must locate the routing cache entry corresponding to the source
  528.    of the Reply MTU option; if no such entry exists, a new one (with
  529.    default values) should be created.  The SupportsProbe bit is set, and
  530.    the ConsecutiveProbes value is reset to 0.  The ProbeRetry field is
  531.    set to the current time plus ReprobeInterval.
  532.  
  533.    Four cases are possible when a Reply MTU option is received:
  534.  
  535.       (1) The Reply MTU option value is less than the current
  536.           MINMTU: the MINMTU field is set to the new value, and
  537.           the LastDecreased field is set to the current time.
  538.  
  539.       (2) The Reply MTU option value is greater than the
  540.           current MINMTU and the LastDecreased field plus
  541.           IncreaseInterval is less than the current time: set the
  542.           ProbeRetry field to LastDecreased plus IncreaseInterval,
  543.           but do not change MINMTU.
  544.  
  545.       (3) The Reply MTU option value is greater than the
  546.           current MINMTU and the LastDecreased field plus
  547.           IncreaseInterval is greater than the current time: set
  548.           the MINMTU field to the new value.
  549.  
  550.       (4) The Reply MTU option value is equal to the current
  551.           MINMTU: do nothing more.
  552.  
  553.    Whenever the MTU field is changed, the transport layer should be
  554.    notified, either by an upcall or by a change in a shared variable
  555.    (which may be accessed from the transport layer by a downcall).
  556.  
  557.    If a fragmentation reassembly timeout occurs, if an ICMP Time
  558.    Exceeded/Fragmentation Reassembly Timeout is received, or if the IP
  559.  
  560.  
  561.  
  562. Mogul, Kent, Partridge, & McCloghrie                           [Page 10]
  563.  
  564. RFC 1063                IP MTU Discovery Options               July 1988
  565.  
  566.  
  567.    layer is asked to send a probe by a higher layer, the ProbeRetry
  568.    field for the appropriate routing cache entry is set to the current
  569.    time.  This will cause a Probe option to be sent with the next
  570.    datagram (unless the SupportsProbe bit is turned off).
  571.  
  572. MANAGEMENT PARAMETERS
  573.  
  574.    We suggest that the following parameters be made available to local
  575.    applications and remote network management systems:
  576.  
  577.       (1) The number of probe retries to be made before determining
  578.           a system is down.  The value of 10 is certain to be wrong
  579.           in some situations.
  580.  
  581.       (2) The frequency with which probes are sent.  Systems may
  582.           find that more or less frequent probing is more cost
  583.           effective.
  584.  
  585.       (3) The default MINMTU used to initialize routes.
  586.  
  587.       (4) Applications should have the ability to force a probe
  588.           on a particular route.  There are cases where a probe
  589.           needs to be sent but the sender doesn't know it.  An
  590.           operator must be able to cause a probe in such situations.
  591.           Furthermore, it may be useful for applications to "ping"
  592.           for the MTU.
  593.  
  594. REFERENCES
  595.  
  596.    [1]  Kent, C. and J. Mogul, "Fragmentation Considered
  597.         Harmful", Proc. ACM SIGCOMM '87, Stowe, VT, August 1987.
  598.  
  599.    [2]  Postel, J., Ed., "Internet Protocol", RFC-791,
  600.         USC/Information Sciences Institute, Marina del Rey, CA,
  601.         September 1981.
  602.  
  603.    [3]  Postel, J., Ed., "Transmission Control Protocol", RFC-793,
  604.         USC/Information Sciences Institute, Marina del Rey, CA,
  605.         September 1981.
  606.  
  607.    [4]  Postel, J., "The TCP Maximum Segment Size and Related Topics",
  608.         RFC-879, USC/Information Sciences Institute, Marina del Rey,
  609.         CA, November 1983.
  610.  
  611.  
  612.  
  613.  
  614.  
  615.  
  616.  
  617.  
  618. Mogul, Kent, Partridge, & McCloghrie                           [Page 11]
  619.